1. Statement of the Technical Field
The present invention relates to server performance tuning and more particularly to configuring buffers for optimal server performance.
2. Description of the Related Art
To obtain optimal performance from a network-based server, the server can be fine-tuned for its specific application environment. In the context of the Internet, application environments associated with Web serving include high-performance Web serving, multi-hosting and benchmarking. In the high-performance Web serving environment, the tuning process can focus upon content served in the environment and the anticipated load of a specific Web site hosted in the Web serving environment. By comparison, in the multi-hosting environment, performance tuning can account for the effect of a single server hosting multiple Web sites as is the case typically with an Internet service provider (ISP). Finally, in the benchmarking environment, performance tuning can relate directly to the achievement of the highest performance for a specific set of tests.
For almost any server that provides a network-based service such as a Web server configured for use with the hypertext transfer protocol (HTTP), four basic server components form the foundation of server performance: Processor, Memory, Network and Disk. Basic HTTP serving involving mere static text and images does not consume much processor resources, however, as dynamic elements are added to the Web site, processor performance can become increasingly more of an important factor to be considered. Tuning the processor component typically can involve the optimization of the hosted application, the use of a faster processor, or the augmentation of the number of processors accessible by the server.
Deficiencies within the network component often causes the greatest performance bottlenecks experienced in the server environment. These bottlenecks can occur in direct consequence of the fixed communications bandwidth often afforded to the network interface of the server. In contrast, most recently the disk component has grown to be a de minimus factor of the four components. In this regard, excepting for disk intensive and input/output (I/O) intensive applications hosted within the server, the disk resource often has a negligible impact upon the performance of a server. In the circumstance where the disk resource can have a more substantial impact, tuning techniques such as disk striping can be used to improve I/O and consequently server performance.
By far, memory utilization represents the single most tunable variable of the four performance factors. Memory is vital to server performance and, in the absence of sufficient memory and in the presence of improper tuning, a server can resort to virtual page swapping. As it will be recognized by the skilled artisan, virtual page swapping can impart a tremendous impact upon the performance of an application hosted within a server. Ideally, a server such as a Web server or application server will include enough memory to handle all necessary applications, network buffers, and a performance oriented cache. In this regard, when most or all content hosted within a content server can be cached in an I/O buffer cache rather than remaining on disk, server performance can be enhanced substantially.
For performance critical applications, the ability to serve a range of clients, from one million to ten million, solely rests with how well a communications system can efficiently handle the requested and respondent I/O operations. Generally, in order to speed processing of requests and responses a server can push requests and responses into kernel-level and application-level buffers to allow processing of additional requests and responses. Thus, optimal performance can be obtained by controlling the size and number of network buffers available for use by the communication system of the server.
When sizing buffers, however, it is important to recognize that when a process sends or receives a quantity of data which is larger than an available buffer, the process can push out a buffer-sized chunk first. Subsequently, the process can wait until the data in the buffer has drained before sending the next chunk. Importantly, the process cannot handle another request or response until the last chunk of data has been sent to the buffer. Accordingly, buffers ought to be sized large enough to that server processes need not spend time unnecessarily breaking off chunks of data to send to buffers. Conversely, clients often drop connections with servers leaving large amounts of data in buffers waiting to be drained. Data which never drains from a buffer can be a burden until cleared. Accordingly, buffers ought not be sized too large.
Presently, buffers are sized statically by design. In this regard, the size of kernel-level and application-level buffers can be sized independently of one another and can be “hard-coded” in a configuration repository such as a flat file or a registry. User-level and system-oriented applications traditionally key-off these stored values during initialization as static determinations for the size of newly allocated buffers. Significantly, these values for the size of buffers cannot change dynamically causing significant performance deficiencies arising from environmental changes not present when computing the static determination of buffer size.
The static establishment of buffer size stands in stark contrast to present trends in computing—in particular autonomic computing. In the famed manifesto, Autonomic Computing: IBM's Perspective on the State of Information Technology, Paul Horn, Senior Vice President of IBM Research, observed, “It's not about keeping pace with Moore's Law, but rather dealing with the consequences of its decades-long reign.” Given this observation, Horn suggested a computing parallel to the autonomic nervous system of the biological sciences. Namely, whereas the autonomic nervous system of a human being monitors, regulates, repairs and responds to changing conditions without any conscious effort on the part of the human being, in an autonomic computing system, the system must self-regulate, self-repair and respond to changing conditions, without requiring any conscious effort on the part of the computing system operator.
Thus, while the autonomic nervous system can relieve the human being from the burden of coping with complexity, so too can an autonomic computing system. Rather, the computing system itself can bear the responsibility of coping with its own complexity. The crux of the IBM manifesto relates to eight principal characteristics of an autonomic computing system:    I. The system must “know itself” and include those system components which also possess a system identify.    II. The system must be able to configure and reconfigure itself under varying and unpredictable conditions.    II. The system must never settle for the status quo and the system must always look for ways to optimize its workings.    IV. The system must be self-healing and capable of recovering from routine and extraordinary events that might cause some of its parts to malfunction.    V. The system must be an expert in self-protection.    VI. The system must know its environment and the context surrounding its activity, and act accordingly.    VI. The system must adhere to open standards.    VIII. The system must anticipate the optimized resources needed while keeping its complexity hidden from the user.
Importantly, performance tuning has yet to be viewed from the perspective of the eight tenants of autonomic computing. In particular, whereas autonomic computing requires the notion of self-configuration, management and healing, the manual static sizing of buffers in a communications system hardly constitutes self-configuration. Similarly, the manual modification of hard code to re-size a buffer again does not reflect self-management and self-healing principles. Yet, these four principles provide for the foundation of autonomic computing. Moreover, self-managing systems which comport with the principles of autonomic computing reduce the cost of owning and operating computing systems. Yet, implementing a purely autonomic system has proven revolutionary. Rather, as best expressed in the IBM Corporation white paper, Autonomic Computing Concepts (IBM Corporation 2001)(hereinafter, the “IBM White Paper”), “Delivering system-wide autonomic environments is an evolutionary process enabled by technology, but it is ultimately implemented by each enterprise through the adoption of these technologies and supporting processes.”